# Things a non Programmer can do
## सुनना शुरू करें

सब कुछ ओपन सोर्स में दूसरे लोगों को शामिल करता है। 
आप एक टीम में शामिल होने की कोशिश कर रहे हैं, और इसका मतलब है कि आपको समुदाय को समझना होगा और यह कैसे काम करता है।
एक परियोजना में प्रवेश करके "नमस्ते, यहाँ मुझे लगता है कि इस परियोजना को यह करना चाहिए" कहना आमतौर पर अच्छी बात नहीं मानी जाती है। 
कुछ परियोजनाएं इस तरह के दृष्टिकोण का स्वागत कर सकती हैं, लेकिन यदि परियोजना काफी समय से चल रही है, तो इस अवधारणा को स्वीकार करने की संभावना कम होती है।
**परियोजना की आवश्यकताओं को जानने के लिए सुनना सबसे अच्छा तरीका है।**

1. **मेलिंग सूची में शामिल हों**: कई परियोजनाओं के लिए, मेलिंग सूची परियोजना के विकास के बारे में संचार का मुख्य साधन होती है।
बड़ी परियोजनाओं में, कई मेलिंग सूची उपलब्ध होती हैं।
उदाहरण के लिए, पोस्टग्रेसक्यूएल परियोजना में कम से कम 12 उपयोगकर्ता-ओरिएंटेड सूचियां और छह डेवलपर सूचियां हैं।
मैं सुझाव देता हूँ कि आप मुख्य उपयोगकर्ता-ओरिएंटेड सूची और मूल डेवलपर सूची का पालन करें, जिसमें सुनना शुरू करें।

2. **एक ब्लॉग का पालन करें**: मूल डेवलपर द्वारा संचालित ब्लॉग आमतौर पर भविष्य में आने वाले रिलीज के बारे में जानकारी देते हैं,
और यहां पहुंचने के लिए क्या किया गया है। एक प्लैनेट साइट परियोजना से संबंधित कई स्रोतों से समाचार और ब्लॉग प्रविष्टियों को संग्रहीत करती है।
यदि कोई प्लैनेट साइट है, जैसे planet.gnome.org या planet.mysql.com, तो वहां से शुरू करें। "प्लैनेट <परियोजनानाम>" के लिए Google में खोजें।

3. **एक IRC चैनल में शामिल हों**: कई ओपन सोर्स परियोजनाओं में विशेष इंटरनेट रिले चैट (IRC) चैनल होते हैं जहां डेवलपर और उपयोगकर्ता समस्याओं और विकास की चर्चा करने के लिए रहते हैं।
परियोजना की वेबसाइट में देखें कि चैनल का नाम क्या है और यह IRC नेटवर्क कहां मिलेगा।

**टिकट के साथ काम करें**
कोड किसी भी ओपन सोर्स परियोजना का हृदय होता है, लेकिन सोचें इसे कि कोड लिखना केवल योगदान करने का एकमात्र तरीका नहीं है।
कोड और कोड के चारों ओर के सिस्टम की रखरखाव को अक्सर नई सुविधाओं को बनाने और बग्स को ठीक करने के दौरान अनदेखा कर दिया जाता है।
इन क्षेत्रों को एक आसान तरीके से परियोजना में कदम रखने का एक अवसर मानें।
अधिकांश परियोजनाएं एक सार्वजनिक दृश्यमान ट्रबल टिकट सिस्टम रखती हैं, जिसका लिंक परियोजना की वेबसाइट के मुख पृष्ठ से जुड़ा होता है और दस्तावेज़ीकरण में शामिल होता है।
यह उपयोगकर्ताओं और डेवलपर्स के बीच संचार का मुख्य माध्यम होता है। इसे अद्यतित रखना परियोजना में मदद करने का एक बड़ा तरीका है।
आपको टिकटिंग सिस्टम में विशेष अनुमतियाँ प्राप्त करने की आवश्यकता हो सकती है, जो अधिकांश परियोजना नेताओं को आपकी मदद करने की इच्छा बताते ही खुशी से देंगे।

4. **एक बग का निदान करें**: बग्स आमतौर पर गलत रूप में रिपोर्ट किए जाते हैं।
एक बग का निदान करना और उसे व्याख्या करना, समस्या के विशेषांकों का पता लगाने के काम में डेवलपर्स को समय बचाने में मदद कर सकता है।
यदि एक उपयोगकर्ता ने "मैं X करते समय सॉफ्टवेयर काम नहीं करता" रिपोर्ट की है, तो कुछ समय निकालें और इस समस्या के कारणों का पता लगाएं।
क्या यह दोहराया जा सकता है? क्या आप समस्या को बार-बार पैदा करने के लिए कुछ स्टेप्स निर्धारित कर सकते हैं? क्या आप समस्या को सीमित कर सकते हैं, जैसे कि यह केवल एक ब्राउज़र पर होता है लेकिन दूसरे पर नहीं या एक डिस्ट्रो पर होता है लेकिन दूसरे पर नहीं?

यदि आपको पता नहीं है कि समस्या का कारण क्या है, तो संकेतों को सीमित करने में जोखिम लेने का प्रयास करने से किसी दूसरे को इसे सुधारना आसान होता है।
चाहे आप कुछ भी खोजें, उसे बग सिस्टम में टिकट में जोड़ें ताकि सभी देख सकें।

5. **ठीक हुए बग्स को बंद करें**: अक्सर बग्स को कोडबेस में ठीक कर लिया जाता है, लेकिन उसके बारे में रिपोर्ट किए गए टिकट सिस्टम में अद्यतित नहीं होते हैं।
इस कचरे को साफ करना समय लेने वाला हो सकता है, लेकिन यह पूरे परियोजने के लिए महत्वपूर्ण है।

एक वर्ष से पुराने टिकटों के लिए टिकट सिस्टम में क्वेरी करें और देखें कि बग अभी भी मौजूद है या नहीं।
बग ठीक हुआ है और बंद किया जा सकता है यह जानने के लिए परियोजना के रिलीज चेंज लॉग की जांच करें।
यदि यह ठीक होने के बारे में ज्ञात है, तो टिकट में संस्करण नंबर नोट करें और उसे बंद करें।

नवीनतम संस्करण के साथ बग को पुनः बनाने का प्रयास करें।
यदि नवीनतम संस्करण के साथ इसे पुनः बनाना संभव नहीं है, तो टिकट में इसे नोट करें और उसे बंद करें।
यदि यह अभी भी मौजूद है, तो टिकट में यह नोट करें और खुले छोड़ दें।

कोड के साथ काम करना
प्रोग्रामर्स, सभी अनुभव स्तरों के, परियोजना में कोड के साथ मदद कर सकते हैं।
सोचें नहीं कि आपको एक कोड जीनियस होना चाहिए ताकि आप अपने पसंदीदा परियोजना में वास्तविक योगदान कर सकें।

यदि आपका काम कोड में संशोधन शामिल है, तो परियोजना द्वारा कोड को योगदानकर्ताओं से प्राप्त करने का तरीका जांचें।
हर परियोजना की अपनी वर्कफ़्लो होती है, इसलिए कोड सबमिट करने से पहले उसके बारे में पूछें।

उदाहरण के लिए, पोस्टग्रेएसक्यूएल (PostgreSQL) परियोजना इसकी प्रक्रिया में बहुत सख्त है: कोड संशोधन पैच रूप में एक मेलिंग सूची में भेजे जाते हैं जहां मुख्य डेवलपर्स बदलाव के हर पहलू की जांच करते हैं। दूसरी तरफ़, पैरॉट जैसी परियोजना में कोडबेस के लिए संबंधित अधिकार प्राप्त करना आसान होता है। यदि परियोजना GitHub का उपयोग करती है, तो GitHub के पुल अनुरोध सुविधा का उपयोग करने वाली एक वर्कफ़्लो हो सकती है। कोई भी दो परियोजनाएँ एक समान नहीं होतीं।

जब भी आप कोड संशोधित करते हैं, सुनिश्चित करें कि आप समुदाय के एक ज़िम्मेदार सदस्य के रूप में कार्य कर रहे हैं और अपने कोड की शैली को कोडबेस के शेष से मेल खाती हो। आपके द्वारा जोड़ा या संशोधित किया गया कोड शेष के जैसा दिखना चाहिए। शायद आपको ब्रेसिंग स्टाइल या इंडेंटेशन के स्थान परस्पर न पसंद हो, लेकिन एक ऐसा कोड बदलाव सबमिट करना असभ्य है जो मौजूदा मानकों से मेल नहीं खाता है। यह कहने के समान है "मुझे आपकी शैली पसंद नहीं है और मुझे लगता है कि मेरी शैली बेहतर है, इसलिए आपको मेरे तरीके से करना चाहिए।"

6. **बीटा या रिलीज कैंडिडेट (beta or release candidate) का परीक्षण करें**: किसी भी परियोजना जो बहुविधियों पर चलाने के लिए डिज़ाइन की गई हो सकती है, कई प्रकार की पोर्टेबिलिटी समस्याएं हो सकती हैं।
जब रिलीज के करीब आती है और एक बीटा या रिलीज कैंडिडेट प्रकाशित होता है, तो परियोजना के नेता की आशा होती है कि इसे कई अलग-अलग लोगों और अलग-अलग प्लेटफ़ॉर्मों पर परीक्षण किया जाए।
आप उन लोगों में से एक हो सकते हैं और सुनिश्चित कर सकते हैं कि पैकेज आपकी प्लेटफ़ॉर्म पर काम करता है।

आमतौर पर आपको केवल सॉफ़्टवेयर को डाउनलोड, बिल्ड और परीक्षण करने की आवश्यकता होती है, लेकिन यदि आप एक असामान्य वितरण या हार्डवेयर पर हैं, तो परियोजना के लिए महत्वपूर्ण मान्यता हो सकती है।
बस यह रिपोर्ट करें कि बिल्ड और परीक्षण काम करता है, जिससे परियोजना के नेता को पता चलता है कि आगामी रिलीज सुदृढ़ है।

7. **एक बग (bug) को ठीक करें** : यह आमतौर पर उन योगदानकर्ताओं के लिए है जो कोड पर काम करना चाहते हैं।
यह सरल है: टिकट सिस्टम में एक रोचक लगने वाले बग ढूंढें और कोड में उसे ठीक करने की कोशिश करें।
अगर यह उचित हो, तो कोड में ठीक करने को दस्तावेज़ीकरण करें।
यदि कोई परियोजना बग ठीक करने के लिए टेस्टों को शामिल करने की आवश्यकता है, तो एक टेस्ट सुइट में एक टेस्ट जोड़ने का एक अच्छा विचार होता है। आप इस अनजान कोडबेस के चारों ओर छूने के दौरान नोट्स रखें। यदि आप बग को ठीक नहीं कर पाते हैं, तो टिकट में दस्तावेज़ करें कि आपने ठीक करने के प्रयास के हिस्से के रूप में क्या खोजा है। आपके द्वारा मिली जानकारी उनकी मदद करती है जो आपके बाद आते हैं।

8. **एक टेस्ट लिखें:** अधिकांश परियोजनाओं में एक टेस्ट सुइट होती है जो कोड का टेस्ट करती है, लेकिन यह मुश्किल है कि कोई ऐसी टेस्ट सुइट हो जो इसे ज्यादा टेस्ट कर सके।
C के लिए gcov जैसा एक टेस्ट कवरेज टूल या Perl के लिए Devel::Cover का उपयोग करें ताकि स्रोत कोड में वे क्षेत्र निश्चित हों जो टेस्ट सुइट द्वारा टेस्ट नहीं होते हैं।
फिर, इसे कवर करने के लिए एक टेस्ट सुइट में एक टेस्ट जोड़ें।

9. **कैंपाइलर चेतावनी (compiler warning) को शांत करें** : बहुत से सी-आधारित परियोजनाओं के बिल्ड प्रक्रिया में अकसर स्क्रीन पर एक अजीब कैंपाइलर चेतावनी दिखाई देती है।
ये चेतावनियाँ आमतौर पर किसी समस्या के संकेतक नहीं होती हैं, लेकिन ऐसा दिख सकता है।
बहुत सारी चेतावनियों के होने से कैंपाइलर ऐसा लग सकता है कि यह झूल रहा है।
देखें कि क्या कोड वास्तव में एक बग को छिपा रह सकता है। यदि नहीं, तो शांत करने के लिए स्रोत को संशोधित करना मददगार होता है ताकि ये गलत चेतावनियाँ छुपा सकें।

10. **टिप्पणी जोड़ें**: कोड में खोज करते समय, आपको कुछ स्थानों पर कंफ़्यूज़ हो सकता है।
संभावना है कि यदि आप कंफ़्यूज़ हो रहे हैं, तो दूसरे भी होंगे। इन्हें कोड में दस्तावेज़ीकरण करें और एक पैच सबमिट करें।

दस्तावेज़ीकरण के साथ काम करें
दस्तावेज़ीकरण आमतौर पर एक परियोजना का वह हिस्सा होता है जिसे कम महत्व दिया जाता है।
यह यह भी संघर्ष कर सकता है क्योंकि इसे उन लोगों की दृष्टि से लिखा गया है जो परियोजना को अच्छी तरह से जानते हैं, बल्कि उनकी नज़रिए से जो इसमें अभी नए हैं।
यदि आपने कभी एक परियोजना के लिए दस्तावेज़ पढ़ी है जहां आपको लगता है, "ऐसा लगता है मानुअल मांगता है कि मेरे पास पहले से ही पैकेज का उपयोग करने का ज्ञान हो," तो आप जानते हैं कि मैं क्या कह रहा हूँ।
अक्सर एक ताजगी वाले नज़रों की संचालन में दस्तावेज़ीकरण में कमी का पता लगा सकती है जिसे परियोजना के नजदीकी लोग नहीं देखते हैं।

11. **एक उदाहरण बनाएं**: कोई परियोजना ऐसी नहीं है जिसमें केवल हो-टू उदाहरण हों।
चाहे यह एक वेब API हो, रूटीन का एक लाइब्रेरी हो, Gimp जैसा एक GUI ऐप हो या कमांड लाइन टूल हो,
सही उपयोग का एक अच्छा उदाहरण सॉफ़्टवेयर के सही उपयोग को पृष्ठों के दस्तावेज़ीकरण से अधिक स्पष्टता और तेज़ी से समझा सकता है।
एक API या लाइब्रेरी के लिए, उपकरण का उपयोग करके एक उदाहरण प्रोग्राम बनाएं। यह आपके द्वारा लिखे गए कोड से निकाला जा सकता है, जिसे नियमित करके कम कर दिया जाए।
टूल के लिए, अपने दैनिक जीवन में इसे कैसे उपयोग किया गया है के वास्तविक उदाहरण दिखाएं। यदि आप दृश्य-ओरिएंटेड हैं,
ऐप्लिकेशन की स्थापना कैसे करें जैसे महत्वपूर्ण प्रक्रिया का स्क्रीन कैप्चर बनाने का विचार करें।
समुदाय के साथ काम करें
ओपन सोर्स केवल कोड के बारे में होता है वही नहीं है। समुदाय ओपन सोर्स को कामयाब बनाता है। यहां वह तरीके हैं जिनसे आप उसे मजबूत कर सकते हैं।

12. **सवाल का जवाब दें**: समुदाय को बनाने की सबसे अच्छी विधि है दूसरों की मदद करना।
एक सवाल का जवाब देना, विशेष रूप से जब उसे शुरुआती तरीके से अभी अभी समझने वाले व्यक्ति से पूछा जाता है, परियोजना को बढ़ाने और मांगलिक बनाने में महत्वपूर्ण होता है।
आपका समय जो आप एक शुरुआत करने वाले की मदद करने में लगाते हैं, यद्यपि वे एक सवाल पूछ रहे हों जहां आप आसानी से तेज़ी से "RTFM" लौटा सकते हैं, तो आपको बाद में समुदाय का एक और सक्रिय सदस्य प्राप्त करने में लाभ मिलता है।
हर कोई कहीं ना कहीं से शुरुआत करता है, और परियोजनाएं जीवंत रहने के लिए निरंतर लोगों के प्रवाह की आवश्यकता होती है।

13. **ब्लॉग पोस्ट लिखें**: यदि आपके पास एक ब्लॉग है, तो उस परियोजना के साथ अपने अनुभवों के बारे में लिखें जिसका आप उपयोग कर रहे हैं।
सॉफ़्टवेयर का उपयोग करते समय आपने किसी समस्या का सामना किया हो तो उसके समाधान के बारे में बताएं।
आप दो तरीकों से मदद कर रहे होंगे, एक तो आप उस परियोजना को आपके चारों ओर रखने में मदद कर रहे होंगे,
और दूसरा, आपकी समस्या को भविष्य में किसी और द्वारा खोजने पर जवाब देने के लिए वेब खोज करने वालों के लिए एक रिकॉर्ड बना रहें होंगे।
(एक आपके तकनीकी एडवेंचर का ब्लॉग उस सॉफ़्टवेयर के साथ वास्तविक दुनिया के अनुभव को दिखाने का एक उत्कृष्ट तरीका हो सकता है जब आप उसका उपयोग करके नौकरी की तलाश में जाते हैं)|

14. **वेबसाइट में सुधार करें**: यदि आपके पास वेब डिज़ाइन के कौशल हैं और आप सहायता करने के लिए वेबसाइट को और इस प्रकरण में प्रोजेक्ट की जनता के सामने छवि को सुधार सकते हैं, तो यह समय बहुत अच्छा बिताया गया होता है।
शायद परियोजना को एक ग्राफ़िक बदल चाहिए, या परियोजना को पहचानने के लिए एक लोगो।
ये सामग्री उन योग्यताओं की कमी हो सकती है जो समुदाय में नहीं हैं। मुझे यह जानकर खुशी होगी कि अगर मेरे परियोजनाओं की वेबसाइटों पर ग्राफ़िक डिज़ाइन मदद मिल सके।

सबसे अधिक महत्वपूर्ण बात यह है कि आप चारों ओर के लोगों के बीच की चर्चा क्या है, इसे सुनें। यदि आप किसी महत्वपूर्ण आवश्यकता को पहचान सकते हैं, तो यह बड़ी बात हो सकती है। उदाहरण के लिए, हाल ही में पैरॉट डेवलपर्स के मेलिंग सूची पर त्रुटि टिकट सिस्टम के रूप में GitHub का उपयोग करने का निर्णय लिया गया, जहां वे पहले वाले Trac स्थापना को छोड़ रहे थे। कुछ लोग इस हरकत के खिलाफ थे क्योंकि उन्हें टिकट को GitHub के सिस्टम में परिवर्तित करने का कोई तरीका नहीं था। एक दिन की बहस के बाद, मैंने उठाने की कोशिश की और कहा "क्या अगर मैं एक कनवर्टर लिखता हूं?" लोग इस विचार से बहुत खुश थे। मैंने 450+ टिकटों के लिए एक कनवर्टर प्रोग्राम लिखने का समय बिताया, इसलिए हमारी टिकट इतिहास में से कोई भी खोने की समस्या नहीं हुई। यह एक बड़ी सफलता थी। मैंने सहयोग किया, और कोर डेवलपर्स पैरॉट पर काम करने के लिए केंद्रित रहे।














